perm filename FORMAT.PRO[DLN,MRC] blob
sn#352666 filedate 1978-05-01 generic text, type C, neo UTF8
COMMENT ā VALID 00003 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 00002 Dialnet memo #4
C00004 00003 DESCRIPTION OF THE FORMAT FOR HIGH-LEVEL DIALNET PROTOCOLS
C00008 ENDMK
Cā;
Dialnet memo #4
SAILON sail on, sail on
Dialnet Protocols
(or, the Protocols of DIAL)
Format for Non-Interactive Tertiary protocols
John McCarthy
12/26/77
These protocols are being developed as part of the Dialnet project at the
Stanford University Artificial Intelligence Laboratory supported by NSF grant
MCS 77-02080 with John McCarthy as Principal Investigator. The project is
described in a paper available online at ARPAnet host SU-AI as
DIALNE.MEM[DLN,MRC] (Dialnet Memo #1).
This is FORMAT.PRO[DLN,MRC] at ARPAnet host SU-AI (octal 13, decimal 11.).
DESCRIPTION OF THE FORMAT FOR HIGH-LEVEL DIALNET PROTOCOLS
All protocol communication in the non-interactive higher level Dialnet
protocols (e.g. MAIL, File Transfer) uses a list format for messages. Each
message therefore has the form
(<identifier> <item> ... <item>)
where the items themselves are either identifiers or have a similar
structure. The object of this scheme is to ensure flexibility.
Suppose, for example, that one of the items in a protocol message
designates a user name. Initial designs of Dialnet may allow only a character
string without parentheses like SMITH to designate the user. Later this might
be elaborated to also allow a complex designator like (SUCCESSOR SMITH) to
designate the person who has replaced SMITH in this job assignment.
There is no present intention that the Dialnet protocols will be subject to
rapid elaboration. The present object is merely to build these protocols so
that they will not be subject to blind alleys. Therefore, there are no fixed
size fields, and item that is initially represented by an atomic name may later
be replaced by some kind of expression, and new terms may be adjoined to lists.
Thus if an item is presently denoted by a three term list, an elaborated
protocol may later call for a four item list, but if the same initial identifier
is used, it should still be possible for a recipient to ignore the fourth item
and still use the message.
We believe that these conventions, at slight cost in initial
implementation, will make future improvements easy should they be required.